home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group03a.txt / 000023_icon-group-sender_Mon Mar 3 08:08:35 2003.msg < prev    next >
Internet Message Format  |  2003-12-22  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id h23F79w16439
  4.     for icon-group-addresses; Mon, 3 Mar 2003 08:07:09 -0700 (MST)
  5. Message-Id: <200303031507.h23F79w16439@baskerville.CS.Arizona.EDU>
  6. From: ernobe <ernobe@yahoo.com>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: GUI Front End for icont
  9. Date: Sat, 01 Mar 2003 16:35:19 -0600
  10. User-Agent: Noworyta News Reader/2.9
  11. To: icon-group@cs.arizona.edu
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13. Status: RO
  14.  
  15. Frank J. Lhota wrote:
  16.  
  17. > In some previous versions of Icon for MS Windows, there were two separate
  18. > sets of Icon tools: one for command line interface  (CLI) applications, and
  19. > one for Graphic User Interface (GUI) applications:
  20. > 
  21. > - For CLI applications, the Icon compiler was called "nticont.exe", and it
  22. > used "nticonx.exe"as the interpreter; and
  23. > - For GUI applications, the Icon compiler was called "wicont.exe", and it
  24. > used "wiconx.exe" as the interpreter.
  25. > 
  26. > Needless to say, the need for the source files to support both sets of tools
  27. > requires lots of MS Win-specific code, creating a maintenance nightmare. As
  28. > a result, the Windows port of Icon has lagged behind ports on other
  29. > platforms.
  30. > 
  31. > I considered this approach unnecessarily complex, so a while back I worked
  32. > on having one set of tools that could be used to build and run both CLI and
  33. > GUI applications. To accomplish this, I ported the Unix Icon code to the
  34. > Cygwin compiler, keeping the MS Windows code for the graphics facility. The
  35. > result of this effort is a icont / iconx pair that can be used to compile
  36. > and execute Icon applications that use CLI, GUI, or both.
  37. > 
  38. > On the one hand, this port was extremely successful. The Cygwin version of
  39. > Icon is much closer to Icon on other platforms, and the number of source
  40. > code differences between Unix Icon and MS Icon has been significantly
  41. > diminished. On the other hand, there is something that has been lost in this
  42. > process. The MS Windows version of the Icon compiler for developing GUI
  43. > application used to be a GUI application itself. This is not the case with
  44. > the Cygwin version of icont.
  45. > 
  46. > Of course, one way we could get back a GUI for compiling and linking Icon
  47. > programs is to develop a GUI front end for the CLI version of icont. 
  48.  
  49. Better yet, why not make a CLI for the Cygwin version of iconx?
  50.  
  51.  
  52.  
  53. > In a
  54. > sense, that is what Microsoft does with its compilers. For all the fancy
  55. > features of Visual C++, when the GUI actually compiles a C/C++ file, it
  56. > simply runs the CLI tool CL.EXE with the appropriate arguments. Presumably,
  57. > this could also be done with icont.
  58. > 
  59. > One could develop the GUI front end using C / C++ and the Win32 API, but if
  60. > we do this, the GUI would only live on the MS Windows platform. A more
  61. > portable approach is possible: why not develop the GUI front end in Icon? By
  62. > doing so, the GUI front end can be ported to any platform where Icon
  63. > supports graphics.
  64. > 
  65. > So, is the Icon graphics facility up to the challenge of the GUI front end?
  66. > 
  67. > 
  68.  
  69.